The present invention relates generally to the field of wireless Local Area Network (LAN) communications, and in particular to establishment and coordination of mobile terminal sleep phases within the LAN.
A new forthcoming standard for wireless LAN services having high throughput, ETSI HIPERLAN Type 2, promises to open new opportunities for both existing applications and new applications. Current versions and approved portions of the proposed ETSI HIPERLAN Type 2 standard are hereby incorporated by reference. HIPERLAN Type 2 LAN networks use a Time Division Duplex (TDD) airlink, meaning that an Access Point (AP) and a Mobile Terminal (MT) in the LAN network both use the same radio frequency to communicate with each other. The AP is connected to a Network (NW) such as an operator""s intranet, and the MT will in most cases be a wireless Network Interface Card (NIC) to a personal computer (PC).
FIG. 1 shows an example configuration for an exemplary HIPERLAN Type 2 system, including an AP 104 within a cell 102. MTs 106, 108 and 110 are also located within the cell 102. As shown in FIG. 1, the AP 104 can communicate via a wireless TDD airlink 112 with, for example, the MT 110. Within each cell, an AP for that cell selects the best frequency with which to communicate with one or more MTs within the cell. The AP""s frequency selection can be based on, for example, the AP""s measurements of interference at other frequencies, as well on measurements made by MTs within the cell.
In accordance with the proposed HIPERLAN Type 2 wireless LAN standard, a wireless LAN system includes a Medium Access Control (MAC) layer, which is implemented as a reservation-based MAC layer. FIG. 2 shows an exemplary MAC data frame 200 having an exemplary MAC frame structure, including a Broadcast Control Channel (BCCH) 202, a Frame Control Channel (FCCH) 204, a Downlink Channel (DLCHAN) 206, an Uplink Channel (ULCHAN) 208, and a Random Access Channel (RACH) 210. As shown in FIG. 2, the boundary between the DLCHAN 206 and the ULCHAN 208, as well as the boundary between the ULCHAN 208 and the RACH 210, can be changed in accordance with traffic requirements. Assuming that the MT 110 has been authenticated and a connection has been established between the MT 110 and the AP 104, then in order to send Uplink (UL) data via the AP 104, the MT 110 monitors the BCCH 202 and the FCCH 204 for the occurrence of random access opportunities. The MT 110 can then request uplink resources via the RACH 210, and the AP 104 will acknowledge the request for uplink resources and start scheduling UL resources in the TDD airlink 112 for use by the MT 110. In other words, when the MT 110 places a request for uplink resources, a reservation-based access starts.
When the AP 104 receives Downlink (DL) data from the network (NW) for the MT 110, the AP 104 either buffers the data and defers transmission of the data to the MT 110 if the MT 110 is sleeping, or transmits the DL data to the MT 110 at the next possible occasion. The AP 104 announces that it has data for the MT 110 (and/or other MT""s within the cell 102) by broadcasting a frame having the format of the frame 200, with a MAC-ID and a Data Link Control Channel ID (DLCC-ID) of the MT 110 in the FCCH 204 following the BCCH 202. In this situation, the FCCH 204 also contains the exact location of the data for the MT 110, in the DLCHAN 206 of the frame 200. An MT having a MAC-ID can have several DLCC-IDs.
Since MTs are often powered by finite sources such as batteries, the HIPERLAN Type 2 standard provides for a sleep mode for the MTs to conserve energy usage by the MTs. This sleep mode is outlined in FIG. 3. As shown in FIG. 3, at a first step 302, an MT sends a sleep request signal, which can include a suggestion by the MT as to how long the sleep interval should be, or in other words, the sleep duration, to an AP. The AP accepts the sleep request signal, decides the starting time and the sleep duration, and then in step 304 sends a sleep reservation signal to the MT indicating the starting time at which the MT should enter the sleep mode, and the sleep duration or time the MT should remain asleep before xe2x80x9cwakingxe2x80x9d to monitor the BCCH of a MAC frame from AP for the occurrence of DL data pending for the MT. The sleep duration can be, for example, an arbitrary number of MAC frames. At step 306 the MT enters the sleep mode, and then when the sleep duration expires at step 308, the MT awakens and monitors the BCCH for indications of DL data pending for the MT. If DL data is pending, the AP will notify the MT via the BCCH and schedule downloading of the DL data to the MT.
In particular, if the MT discerns that the BCCH contains a signal such as a pending data indicator, indicating that downlink data is pending at the AP for an as-yet undetermined MT, then the MT will analyze the content of a Slow Broadcast Channel (SBCH) in the MAC frame for a dedicated wakeup PDU directed to the MT. The SBCH location in the MAC frame is given by an Information Element (IE) in the FCCH. In other words, the MT will check further to determine whether it is the MT (or one of the MTs) for which data is pending. If no downlink data is pending for any MT, then the MT returns to the sleep mode for another sleep duration time period, at the end of which it will awaken and repeat the cycle by monitoring the BCCH for a pending data indicator, etc. If no pending data indicator is present, or if the indicator indicates that no downlink data is pending, then the MT will go back to sleep.
FIG. 4 shows the case where an MT analyzes the SBCH in the MAC frame for a dedicated wakeup PDU. As shown in FIG. 4, when an MT sleep time expires at time 420, the MT first examines the BCCH 410 to determine whether the BCCH 410 contains a pending data indicator indicating that the MAC frame 406 contains data for an MT. The pending data indicator does not indicate which MT that the data, if present, is intended for. If a pending data indicator in the BCCH 410 does indicate that the MAC frame 406 contains data for an as yet unspecified MT, then the MT seeks to determine whether the MAC frame 406 contains data for it. It does so by analyzing the FCCH 412 for an indication as to where the SBCH 418 begins in the MAC frame. For example, the FCCH 412 can contain a predefined Information Element (IE) 414 that indicates where the SBCH 418 begins. For example, the predefined IE 414 can be defined to include a MAC-Identification (MAC-ID)=0 and a Downlink Control Channel Identification (DLCC-ID)=0.
The SBCH is located in the DLCHAN of the MAC frame 406. A DLCHAN can contain, or host, several logical channels, including the SBCH. These channels can include, for example, a User Data Channel (UDC), a DLC Control Channel (DLCH), where DLC stands for xe2x80x9cData Link Controlxe2x80x9d, a Dedicated Control Channel (DCCH), an In-Band Channel (IBCH), and the Slow Broadcast Channel (SBCH) mentioned above.
The MT then analyzes the SBCH 418 to determine if the SBCH 418 contains any wake-up PDUs that include the MT""s MAC-ID. If yes, then the MT knows that downlink data is pending for it, and the MT will stay active to receive the downlink data. If no, then the MT knows that no downlink data is pending for it, and it returns to the sleep mode automatically without announcement to the AP.
In a case where the MT has pending uplink data for transfer to the AP, then the MT can cut short its sleep duration timer or time period and request uplink resources from the AP by, for example, sending an uplink resource request signal on the RACH 210 of a MAC frame 200.
In Mobitex and pACT (Personal Air Communications System) systems, mobiles must know the concept of different sleep phases, which is not the case for HIPERLAN Type 2.
However, the methods described above suffer several drawbacks. For example, when the MT fails to properly decode the BCCH, FCCH and SBCH upon scheduled wakeup, the behavior of the MT and the AP is unknown. If the MT is presumed to go back to sleep when it fails to decode the BCCH, FCCH or SBCH, then the AP cannot discern whether the MT successfully decoded the wakeup information (for example a wakeup announcement) sent from the AP to wakeup the MT, or whether the AP failed to properly decode or perceive an acknowledgment from the MT (in situations where, for example, the wakeup information instructs the MT to send an acknowledgment signal such as a predetermined signal back to the AP on a reserved uplink channel in the MAC frame that is identified in the wakeup information, or via the next available RACH). The wakeup information can be, for example, in a first case, a wakeup Information Element (IE) located in the FCCH, or in a second case, a wakeup Packet Data Unit (PDU) located in the SBCH.
The AP also cannot discern a situation where the MT failed to properly decode the BCCH, FCCH, or SBCH. In other words, the AP cannot definitively discern the status of the MT. Furthermore, since in the situation where the MT fails to properly decode the BCCH, FCCH or SBCH, the MT is presumed to go back to sleep, the AP must wait until the MT again wakes up before again attempting to establish communication with the MT.
In particular, if the AP sent a wakeup announcement to an MT and the MT failed to properly decode the BCCH, FCCH or SBCH and thus missed a wakeup IE or PDU intended for the MT, (where a MAC-ID in the wakeup IE or PDU that matches the MAC-ID of the MT indicates that the wakeup IE or PDU is intended for the MT), the AP may presume that the MT successfully received the wakeup announcement and is prepared to receive downlink data. Then, the AP will start transmitting downlink data that is pending for the MT. If the MT is not active but instead went back to sleep after missing the wakeup announcement, the retransmission timers in the AP may time out before the MT again awakens to check for pending downlink data, which can cause the AP to remove the MT from a list of MTs that it knows are present in its cell.
Furthermore, if an MT is required to send a new sleep request signal to the AP upon a failure to decode the BCCH, FCCH, or SBCH, the sleep request signal can collide with other data traffic in the MAC frame and lead to unpredicted delays and cumbersome situations for the AP to untangle and resolve. If transmission for all of the MTs to whom a wakeup announcement was transmitted is deferred until the AP can determine that all MTs intending to transmit sleep request signals have done so, then data transmission between the AP and one or more of the MTs can be undesirably delayed.
In accordance with an exemplary embodiment of the invention, where a type of a wakeup announcement to an MT can indicate whether the MT is required to acknowledge the wakeup announcement, when the MT fails to decode a BCCH, FCCH or SBCH that may contain a wakeup announcement for the MT, the MT decodes subsequent MAC frames to look for the presence of a new wakeup announcement for the MT from the AP.
In accordance with another embodiment of the invention, depending on an amount of traffic present and on algorithms implemented in a scheduler and a sleep announcement entity in the AP, a second wakeup announcement directed to an MT can be included in a next MAC frame following a MAC frame that contained a first wakeup announcement for the MT. As traffic increases, a probability that the second wakeup announcement will be included in a MAC frame subsequent to the next MAC frame following the MAC frame that contained the first wakeup announcement, also increases.
In accordance with another embodiment of the invention, after unsuccessfully decoding a BCCH, FCCH or SBCH that may contain a wakeup announcement for the MT, the MT shall continue to monitor subsequent MAC frames for the occurrence of a wakeup announcement for the MT, until either a predetermined number (Nframes) of MAC frames have transpired, or the MT successfully receives a wakeup announcement. When the MT successfully receives a wakeup announcement, it will remain awake.
In accordance with another embodiment of the invention, when the AP sends a wakeup announcement to an MT indicating that downlink data is pending for the MT, the AP shall proceed as if the MT were active, or in other words, awake. Depending on whether the AP is polling the MT prior to sending data (by, for example, sending a wakeup announcement indicating that the MT should send an acknowledge signal back to the MT), the AP shall retransmit the polling request a configurable number of times, for example until a predetermined number of MAC frames have transpired.
If no polling is used, then the AP shall continue to transmit or retransmit data a configurable number of times until, for example, a predetermined number (Nframes) of MAC frames have transpired. The configurable number can be based on or limited by a maximum allowed number of retransmissions.
In accordance with embodiments of the invention, these features can also variously combined.